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ABSTRACT 


The  Foundation  Initiative  2010  (FI  2010)  project  is  an  interoperability  initiative  of  the  Director, 
Test,  Systems  Engineering  and  Evaluation,  Office  of  the  Under  Secretary  of  Defense  (Acquisition  and 
Technology),  funded  through  the  Central  Test  and  Evaluation  Investment  Program  (CTEIP).  The  Army 
is  the  lead  service  for  execution,  with  Navy  and  Air  Force  support.  The  FI  2010  effort  is  postured  to 
improve  systems  development,  testing,  training  and  fielding  through  the  application  of  object-oriented 
systems  interoperability  between  simulations,  hardware-in-the-loop  (HITL)  test  laboratories, 
live/operational  tests,  and  training  systems.  The  FI  2010  concept  builds  on  High-Level  Architecture 
(HLA)  and  Test  &  Training  Enabling  Network  Architecture  (TENA)  standards  and  includes  a  core  set  of 
tools,  inter-range  communication  capabilities,  interfaces  to  existing  assets,  a  repository  of  reusable 
software  and  procedures  for  conducting  an  object-oriented  exercise. 

FI  2010  serves  as  the  foundation  upon  which  ranges  will  want  to  build  their  future  investments. 
Therefore,  the  development  strategy  relies  upon  partnering  with  ranges  from  the  beginning,  and  this  is 
accomplished  through  the  creation  of  development  test  cells  and  coordination  with  Range  Commanders 
Council  and  the  Common  Test  and  Training  Range  Architecture  working  groups.  This  paper  provides 
an  overview  of  the  FI  2010  project  and  supplies  details  of  the  objectives  to  be  accomplished  in  FY  98. 
These  include  tests  and  assessments  of  the  simulation  and  federation  object  model  development  tools 
provided  by  the  Defense  Modeling  and  Simulation  Office  and  a  synthesis  of  requirements  for  a  universal, 
flexible  display  engine  with  reusable  components.  They  also  include  a  check-out  of  the  latest  HLA 
runtime  infrastructure  and  a  Hardware-in-the-Loop  to  Open  Air  Range  interaction  investigation  involving 
the  Naval  Undersea  Warfare  Center,  the  Air  Force  Development  Test  Center  and  the  Naval  Air  Warfare 
Center.  A  video  documentary  of  this  investigation  will  be  provided  as  part  of  the  paper  presentation. 


1.0  Introduction 

The  Foundation  Initiative  (FI)  2010  project  responds  to  Defense  Science  Board  recommendations 
to  establish  standards,  facilitate  interoperability,  and  fully  internet  test  and  training  ranges  and  facilities. 
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FI  2010  also  responds  to  the  increasing  use  of  Modeling  and  Simulation  (M&S)  in  general  and  to  the 
Simulation  Based  Acquisition  (SBA)  and  Simulate,  Test,  Evaluate  Process  (STEP)  initiative  of  the  Under 
Secretary  of  Defense  (USD)  for  Acquisition  and  Technology  (A&T)  in  particular.  The  architecture  and 
products  delivered  by  FI  2010  are  intended  to: 

1)  Reduce  duplication  and  the  cost  of  procurement  and  maintenance  of  range  instrumentation  and 
software. 

2)  Facilitate  the  integration  of  T&E  and  training  range  assets  across  multiple  ranges. 

3)  Facilitate  the  integration  of  live,  virtual  and  constructive  simulations  to  create  the  larger,  more 
complex,  and  more  realistic  test  and  training  battlespace  environments  demanded  by  modern  weapons 
systems  and  tactics. 

The  FI  2010  Project  was  established  at  the  beginning  of  Fiscal  Year  (FY)  1998  at  the 
recommendation  of  the  Test  and  Evaluation  Reliance  and  Investment  Board  (TERIB).  It  consolidated 
four  existing  Central  Test  and  Evaluation  Investment  Program  (CTEIP)  Projects:  the  Test  and  Training 
Enabling  Architecture  (TENA),  Common  Display  and  Processing  Systems  (CD APS),  Virtual  Test  and 
Training  Range  (VTTR)  and  the  Joint  Regional  Range  Complex  (JRRC).  The  products  and  commodities 
developed  will  entail  concepts  that  foster  extensive  software  reuse,  use  advanced  computational 
developments,  and  exploit  distributed  interactive  simulation  techniques  and  commercial-off-the-shelf 
technologies  (COTS),  where  applicable.  The  products  will  include  sets  of  common,  integrated  software 
capabilities  and  processes  to  significantly  improve  the  capability  to  configure  and  re-configure 
instrumentation  resources  to  acquire,  network,  process,  display,  and  archive  data  in  support  of  T&E 
missions  and  training  exercises. 

The  Full  Operational  Capability  (FOC)  to  be  provided  by  the  FI  2010  architecture  and  products  is 
notionally  referred  to  as  the  Logical  Range — a  set  of  live,  constructive  and  virtual  resources  assembled 
into  a  system  of  systems  to  support  a  specific  test  mission  or  training  exercise.  The  Concept  of 
Operations  (ConOps)  for  the  Logical  Range  is  defined  in  the  document  of  the  same  name  dated  March 
1997  (Draft). 

A  simple  example  of  a  logical  range  is  illustrated  in  Figure  1.  The  Navy  Synthetic  Environment  for 
Tactical  Integration  (SETI)  program  integrates  high  fidelity  torpedo  simulation  capabilities  with  live 
Fleet  submarines  operating  at  depth  and  speed  on  range.  Using  SETI,  a  submarine  can  fire  on  a  live 
target  using  the  Hardware  In  The  Loop  (HWIL)  torpedo  in  the  Weapons  Analysis  Facility  (WAF)  at  the 
Naval  Undersea  Warfare  Center  (NUWC)  Division  Newport.  Both  firing  and  target  submarines  can 
“see”  the  simulated  torpedo  in  real-time  while  submerged  thus  allowing  for  weapons  wire  guidance  and 
target  evasion.  With  planned  connectivity  enhancements  SETI  will  provide  simulated  targets, 
countermeasures  and  ocean  environments.  The  benefits  of  SETI  include  unlimited  availability  of  virtual 
torpedoes  to  support  crew  training  and  torpedo  hit  or  miss  assessments,  capabilities  previously 
unavailable  or  unaffordable. 


Synthetic  Environment  for 
Tactical  Integration  (SET!) 


Figure  1.  Synthetic  Environment  for  Tactical  Integration  Exercise 

The  SETI  project  is  one  of  three  FI  2010  exercises  to  be  conducted  in  FY  98.  The  remaining  two 
are  illustrated  in  Figures  2  and  3  below.  Their  purpose  is  to  gain  broad-based  insight  into  the  utility  and 
feasibility  of  conducting  distributed  synthetic  and  live  testing  and  training  events  using  a  common 
architecture  and  reusable  software  tools.  The  FY  98  exercises  focus  on  linking  hardware-in-the-loop 
facilities  and  open  air  ranges,  and  each  investigates  alternative  configurations,  interfaces  and  procedures. 

The  Joint  Advanced  Distributed  Simulation  (JADS)  System  Integration  Test  (SIT)  II  is  a  follow- 
on  to  the  Advanced  Distributed  Simulation  (ADS)  test  conducted  in  FY97  by  the  JADS  Joint  Test 
Force.  Using  HLA  instead  of  a  Distributed  Interactive  Simulation  (DIS)  implementation,  the  JADS  SIT 
II  replicates  the  original  JADS  SIT  risk  mitigation  test  scenario,  linking  the  Pre-flight  Integration  of 
Munitions  and  Electronic  Systems  (PRIMES),  the  Guided  Weapon  Effectiveness  Facility  (GWEF),  and 
the  Central  Control  Facility  (CCF)  at  the  Air  Force  Development  Test  Center,  Eglin  AFB,  FL. 
Operated  and  maintained  by  range  personnel,  a  Development  Test  Cell  (DTC)  emulating  the  Major 
Range  and  Test  Facility  Base  has  been  established  to  cost-effectively  develop,  test,  and  validate  the 
software  interfaces  and  exercise  tools  in  a  controlled  environment.  Toward  our  ultimate  goal  of  range 
interoperability  and  reuse,  the  JADS  SIT  II  exercise  serves  to  be  an  integral  step  -  generating  comparison 
data  to  past  DIS  methodologies,  identifying  potential  HLA  shortfalls  to  be  rectified  by  Test  and 
Evaluation  Enabling  Architecture  (TEN A),  and  providing  insight  (when  combined  with  results  from 
other  exercises)  to  the  common  aspects  among  ranges  and  facilities  ideal  for  standardization. 


Figure  2.  Joint  Advanced  Distributed  Simulation  (JADS)  System  Integration  Test,  Version  II 
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Figure  3.  Simulated  High  Speed  Anti-Radiation  Missile  (SimHARM)  Exercise,  Linking  an 
Installed  Systems  Test  Facility  (ISTF)  to  an  Open  Air  Range  (OAR). 
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2.0  The  Need  for  a  New  “Foundation” 


The  conceptual  framework  for  military  operations  defined  in  Joint  Vision  2010  is  of  size, 
scale,  and  scope  that  cannot  be  physically,  technically,  or  economically  recreated  within  the 
existing  DoD  Test  and  Training  infrastructure.  DoD  Test  and  Training  facilities  have  heretofore 
evolved  autonomously,  resulting  in  duplication  of  effort  and  resources,  differing  processes  and 
procedures,  and  wide  variations  in  the  age,  type,  and  capability  of  basic  Test  and  Training 
resources  such  as  instrumentation,  computers,  software,  communication  systems,  and  data 
displays.  These  variations  limit  the  interoperability,  sharing  and  reuse  of  resources  demanded  by 
the  Joint  Vision  paradigm.  In  addition,  the  increasing  use  of  modeling  and  simulation  in  support 
of  acquisition  streamlining  portends  a  new  era  of  duplication  and  disparity  if  a  interoperability 
common  framework  is  not  established  soon.  A  clear  advantage  of  using  modeling  and  simulation 
in  test  and  evaluation  is  the  potential  to  conduct  distributed  operations  across  a  common 
network.  To  make  this  happen,  participating  models  and  simulations  must  have  the  ability  to 
interact,  and  FI  2010  is  charged  with  developing  a  promulgating  the  capabilities  that  will  make 
this  interaction  practical. 


3.0  FI  2010  Architecture  and  Products  Characteristics 

The  FI  2010  architecture  and  products  are  designed  to  support  the  full  spectrum  of  Test 
and  Training  facilities  including  Open  Air  Ranges  (OARs),  Systems  Integration  Laboratories 
(SILs),  Hardware  in  the  Loop  (HWIL)  Facilities,  Measurement  Facilities  (MFs),  Installed 
System  Test  Facilities  (ISTFs),  and  constructive,  live,  and  virtual  Models  and  Simulations. 

Several  characteristics  are  required  to  foster  interoperability,  sharing,  reuse  and  multi- 
domain  polymorphic  applications.  Many  of  these  characteristics  are  key  to  successfully 
implementing  the  logical  range  concept.  All  play  a  role  in  reducing  duplication  and  cost  in  range 
infrastructure  developments  and  in  providing  the  desired  multi-domain  applicability  to  support 
the  full  spectrum  of  Test  and  Training  facilities. 

3.1  Distributability 

The  FI  2010  architecture  and  products  will  support  execution  on  multiple  hardware 
platforms  that  are  geographically  distributed  and  connected  via  one  or  more  communication 
networks.  Multiple  users  will  be  able  to  access  data  from  various  databases  in  order  to  plan 
potential  exercises,  and  will  be  able  to  query  potential  participants  about  their  availability  and 
current  or  projected  operational  capabilities. 


3.2  Extensibility 

The  architecture  will  also  allow  LR  components  to  be  easily  upgraded  or  modified  to 
support  add-on  requirements  without  requiring  restructuring  of  the  existing  architecture.  Add¬ 
ons  could  include  providing  more  and/or  different  workstations  from  which  planning  and  exercise 
control  would  be  conducted,  incorporating  new  data  networks,  including  new  sensors,  and 
weapons  and/or  models  to  simulate  them,  etc. 

3.3  Interoperability 

Systems,  units,  or  forces  must  be  able  to  provide  and  receive  services  from  other  systems, 
units  or  forces,  and  to  use  the  services  such  that  they  can  operate  together  effectively. 
Interoperability  is  a  system  characteristic,  which  allows  the  assets  of  one  test  or  training  facility 
to  be  used  and  controlled  by  one  or  more  other  facilities  “on  demand”;  as  seamlessly  as  if  they 
were  an  integral  part  of  their  organic  systems. 

3.4  Modifiability 

The  FI  2010  architecture  and  products  will  support,  to  the  maximum  extent  possible,  the 
ability  of  a  hardware  or  software  component  to  be  easily  modified  to  perform  various  tasks,  to 
operate  within  new  systems  or  environments,  or  to  adapt  to  changes  in  scope  or  magnitude  of 
performance  requirements.  Modifiability  often  depends  on  an  item’s  modularity  and  use  of 
standard  interfaces  and  is  normally  more  easily  achieved  with  software.  As  an  example,  to  be 
modifiable  the  simulation  of  a  sensor  or  weapon  system  must  provide  for  the  various 
performance  parameter  values  to  be  determined  by  preset  and  easily  changeable  data  files/tables 
rather  than  “hard”  coded. 

3.5  Portability 

This  is  the  ability  of  a  system,  hardware  or  software  component,  or  data  to  be  easily 
transferred  from  one  hardware  or  software  environment/system  to  another.  This  requires  the 
existence  and  use  of  common  interfaces  so  that  hardware/software  components  and  data  can  be 
easily  inserted  into  various  environments/systems  with  minimal  reformatting  or  interface 
modification.  FI  2010  will  assist  in  the  development  of  commercial  standards  to  promote 
development  of  common  interfaces  needed  for  portability. 

3.6  Reusability 

Reusability  is  the  ability  to  use  the  same  products  and  capabilities  at  multiple  ranges  and 
facilities.  An  example  product  might  be  a  graphical  display  software  package.  Other  examples 
may  include  processes,  procedures  and  documentation  templates  (e.g.,  design,  test,  standards). 
Reuse  supports  a  common-core  of  a  product  that  is,  in  fact,  exactly  the  same  from  instance  to 
instance  of  that  product,  and  it  also  supports  the  ability  to  adapt  the  reusable  product  in 
predetermined  ways  at  the  level  of  a  local  instance.  Reuse  is  distinct  from  commonality  in  that 
commonality  implies  every  instance  of  the  reused  product  is  exactly  the  same.  Effective  reuse  is 
an  optimization  of  commonality  and  flexibility  that  recognizes  the  unique  requirements  of 
individual  ranges  and  facilities  within  a  common  core  environment  or  domain.  Reuse  enables 
significant  savings  in  long-term  development  and  maintenance  costs  and  is  an  effective  and 
efficient  path  to  sharing  and  interoperability. 


3.7  Scaleability 

Scaleability  is  the  ability  to  use  the  same  architecture  and  application  software  on  many 
different  classes  of  hardware/software  platforms  from  personal  computers  to  supercomputers 
and  for  tasks  varying  in  scope  and  complexity  (extends  the  portability  concept).  The  capability 
to  handle  various  operations  of  greatly  different  scales  of  operational  requirements  and  to  be  able 
to  easily  grow  to  accommodate  increased  workloads  beyond  the  initial  capability.  An  example  of 
scaleability  in  the  LR  context  is  to  be  able  to  run  a  single  vehicle  exercise  at  a  single  range  or  a 
multi-vehicle  exercise  at  multiple  ranges  and  other  facilities  with  the  same  basic  system. 

3.8  Sharability 

The  FI  2010  architecture  and  products  shall  support  sharing  which  is  defined  as  the 
ability  of  one  facility  to  directly  use  the  products  generated  by  another  facility.  Interoperability 
is  the  most  extensive  form  of  sharing,  but  is  not  the  only  form.  This  definition  of  sharing 
includes  a  variety  of  “one-way”  information  exchanges  where  data  or  data  products  are  sent  to 
many  facilities,  but  control  of  the  data  generation  is  strictly  at  one  source.  An  example  of  this 
capability  is  the  effective  transmission  of  post-test  analysis  products  without  custom  translation 
required  for  each  product  user. 

3.9  Usability 

The  FI  2010  products  will  enable  the  LR  users  to  perform  their  tasks  effectively  and 
efficiently.  A  usable  system  is  can  be  used  by  a  variety  of  system  operators  for  a  variety  of 
tasks.  Although  operators  may  have  unique  or  specialized  skills  (e.g.  test  conductors,  flutter 
engineers,  graphics  operator,  etc.),  they  should  not  need  special  training  to  use  those  skills  via 
standard  system  interfaces.  Operator  interfaces  will  be  “friendly,”  and  operators  will  be  able  to 
perform  their  tasks  following  the  instructions  and  guidance  provided  in  manuals  or  on-line  help. 
Operator  entries  will  be  by  point  and  click  (mouse,  track  ball,  etc.),  pull-down  menu  selection, 
keyboard,  or  other  simple  interface  device. 

4.0  Operating  a  Logical  Range 

The  FI  2010  architecture  and  products  will  support  the  ability  to  rapidly  define,  setup 
and  execute  a  logical  range  and  its  associated  battlespace  environment  for  a  test  mission  or 
training  exercise  by  assembling  and  managing  the  necessary  resources  from  a  pool  of  available 
live,  constructive,  and  virtual  resources.  Regardless  of  whether  the  particular  resources  used  for  a 
given  event  are  actual  or  simulated,  the  objectives  of  the  event  are  the  same:  to  accurately  test  and 
/  or  evaluate  the  performance  of  a  system  under  test  (SUT)  or  training  participant  under  a  certain 
set  of  conditions.  This  is  accomplished,  usually  in  a  stand-alone  mode  today  through  the  use  of 
numerous  T&E  and  Training  support  resources  known  commonly  as  OARs,  SILs,  HWIL 
facilities,  MFs,  ISTFs,  and  M&S  facilities.  Meeting  the  objectives  of  reducing  duplication, 
facilitating  the  integration  of  T&E  and  training  range  assets,  and  facilitating  the  integration  of  live, 
virtual,  and  constructive  simulations  requires  that  the  capabilities  to  define,  setup  (configure),  and 
operate  the  assets  (e.g.,  instrumentation,  environment  generators,  stimulators)  be  drawn  from  a 
common  framework.  This  is  also  true  for  the  assets  used  in  conducting  post-event  analysis. 


-4- 


4.1  Defining  a  Logical  Range 

Current  methods  of  defining  the  specific  assets  of  T&E  and  Training  support  resources 
are  predominantly  unique  to  the  particular  resources  being  considered.  Referring  back  to  the 
SETI  experiment  as  an  example,  the  means  for  defining  what  torpedo  information  needs  to  be 
available  during  the  conduct  of  that  exercise  (e.g.,  speed,  heading,  position)  would  be  different  for: 
an  actual  firing  of  a  torpedo  at  AUTEC  (underwater  ‘OAR’),  a  simulated  torpedo  launch  in  the 
WAF  (HWIL  facility),  or  a  synthetic  torpedo  launch  in  a  M&S  facility.  This  could  potentially 
be  true  for  all  of  the  participants  required  for  a  particular  LR  instance  (i.e.,  test  mission  or 
training  event).  Recognizing  that  the  cost  of  defining  the  assets  required  for  a  logical  range 
operation  must  be  significantly  less  than  the  current,  aggregate  cost  of  defining  these  assets  for 
stand-alone  operations,  the  logical  range  will  provide  the  definition  capabilities  as  described 
below.  These  capabilities  will  be  common  among  the  various  resources  being  assembled  for  a 
logical  range  operation  and  transparent  to  the  user  with  respect  to  the  specific  resource  from 
which  the  asset  is  being  identified  (eg.,  OAR,  HWIL,  or  M&S  based). 

Resource  Asset  Identification.  This  identification  capability  includes  asset  attributes 
such  as  name,  type,  location,  input  data,  and  output  data.  An  example  of  a  resource  asset  would 
be  a  radar  (of  type  FPS-16  with  output  data  of  range,  azimuth,  elevation,  and  time). 

Resource  Asset  Definition.  A  logical  range  resource  asset  definition  allows  a  logical  range 
operation  planner  to  define,  where  necessary,  the  operation  unique  resource  asset  information. 
An  example  of  such  an  asset  would  be  a  telemetry  system.  The  format  of  the  input  stream,  the 
processing  to  be  applied  to  each  raw  data  item  decommutated  from  the  stream,  and  the 
engineering  units  of  the  resulting  data  items  are  specific  to  a  particular  logical  range  operation. 

Resource  Repository.  This  repository  shall  includes  typical  data  base  capabilities  to 
store,  search,  retrieve,  copy,  and  modify  entries.  Entries  will  consist  of  the  resource  asset 
identification  and  definition  information.  It  will  also  ensure  that  information  is  provided  in  a 
FI2010  compliant  format. 

Resource  Browser.  A  resource  browser  capability  allows  remote  access  to  the  resource 
repository.  This  access  capability  will  be  available  via  existing  community  desktop  computer 
systems  (i.e.,  no  logical  range-specific  or  unique  equipment). 

Logical  Ranee  Definition  Capability.  This  includes  the  means  to  assemble  resource  assets 
from  the  resource  asset  repository  in  accordance  with  the  specific  requirements  of  a  mission  or 
exercise.  It  includes  the  capability  to  designate  primary  and  secondary  resource  assets  to 
accommodate  the  rapid  reconfiguration  of  a  logical  range  due  to  failures  and  scheduling  conflicts 
associated  with  designated  primary  resource  assets  during  LR  operations. 

Logical  Range  Repository.  This  repository  will  include  typical  data  base  capabilities  to 
store,  search,  retrieve,  copy,  and  modify  entries.  These  entries  will  consist  of  logical  range 
instances  stored  via  the  logical  range  definition  capability.  It  shall  also  ensure  that  information  is 
provided  in  a  FI2010  compliant  format. 

Logical  Range  Definition  Utilities.  The  following  utilities  will  be  provided  to  support  the 
logical  range  definition  capability: 

Performance  Prediction.  This  utility  shall  analyze  the  resource  asset  interactions  defined 


-5- 


for  a  particular  operation  and  identify  potential  performance  discrepancies.  This  shall  include 
items  such  as  network  bandwidth,  missing  data  items,  mismatched  data  item  formats,  and 
mismatched  data  rates.  Using  the  SETI  experiment  as  an  example,  the  position  of  the  launching 
submarine  would  be  identified  as  a  missing  data  item  were  it  not  defined  for  the  AUTEC  range 
asset  as  it  is  a  required  input  to  the  torpedo  systems  of  the  WAF  asset.  A  mismatched  data  item 
format  would  be  detected  if  the  AUTEC  range  asset  defined  the  submarine’s  depth  in  feet  when 
the  WAF  is  defined  to  accept  it  in  meters. 

Network  Simulation.  This  capability  provides  the  means,  based  upon  the  resource  assets 
and  network  assets  defined  for  a  particular  LR  operation,  to  simulate  the  planned  LR  network. 
This  simulation  capability  provides  the  user  with  the  capability  to  identify  potential  bandwidth, 
latency,  protocol,  and  general  LR  asset  interaction  discrepancies  of  the  actual  operation  but 
without  directly  utilizing  the  physical  resources. 

Logical  Ranee  Configuration  File  Generation.  This  capability  generates  the  files  required 
to  configure  the  assets  for  a  specific  logical  range  defined  within  the  logical  range  repository  and 
selected  by  the  user. 

4.2  Logical  Range  Setup 

Logical  Range  Setup  capabilities  will  include: 

a.  Scheduling.  Scheduling  capabilities  facilitate  planning  for  the  execution  of  an  exercise  or 
test  on  the  logical  range.  Scheduling  capabilities  will  accommodate,  to  the  maximum 
extent  practical,  the  various  scheduling  and  accounting  systems  in  use  at  DoD  and 
contractor  ranges  and  facilities. 

b.  Network  Setup  Support.  The  Network  Setup  Support  Capability  will  support  the 
translation  of  the  logical  network  defined  during  the  logical  range  definition  phase  into  the 
physical  network  required  to  execute  the  logical  range  task.  The  Network  Setup  Support 
Capability  will  also  support  testing  of  the  physical  network  prior  to  execution. 

Test  Capabilities  will  include: 

1)  Component  Compliance  Test.  This  capability  will  be  used  to  support  testing  of 
each  simulation  for  compliance  with  its  definition  and  with  the  definition  for  the 
logical  range  before  interaction  is  attempted  with  external  simulations. 

2)  One-on-one  Interaction  Testing.  One-on-one  Interaction  Testing  capabilities  will 
support  testing  the  interactions  between  each  pair  of  components  in  the  logical 
range  definition  to  ensure  that  interactions  occur  as  expected. 

3)  Manv-on-manv  Interaction  Testing.  Many-on-many  Interaction  Testing 
capabilities  will  support  testing  the  interactions  that  are  expected  between 
components  in  the  exercise  environment. 

4)  End-to-end  Testing.  End-to-end  testing  capabilities  will  support  testing  the 
interactions  of  all  resources  in  the  logical  range.  End-to-end  testing  is  a  complete 
rehearsal  of  the  test/training  exercise  scenario. 
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4.3  Logical  Range  Execution  Management 

Logical  Range  Execution  Management  will  include: 


a.  Logical  Range  Control.  Logical  range  control  capabilities  will  provide  for  human  control, 
monitoring,  and  visualization  of  the  LR  during  the  execution  of  its  resources.  These 
include  Resource,  Network,  Initialization,  and  Execution  applications. 

b.  Logical  Range  Monitors.  Monitors  support  the  Control  capabilities  and  will  support 
monitoring  the  real-time  operation  of  the  logical  range.  Logical  range  monitors  include: 

1)  A  Network  Traffic  Monitor  to  display  status  and  control  the  flow  of  messaging  on 
the  logical  range  network. 

2)  A  Message  Monitor  to  monitor  and  keep  track  of  the  message  traffic  between  the 
various  resources  of  the  logical  range. 

3)  A  Data  Monitor  to  track  the  data  being  captured,  perform  quality  checks,  and  display 
data  on  request. 

c.  Visualization  Capabilities.  Visualization  capabilities  will  support  the  display  of  standard 
tactical,  three-dimensional  viewport,  and  graphical  data  and  events  and  are  used  both  for 
real-time  visualization  of  events  and  post-test  review  and  analysis. 

d.  Data  Logging  and  Archiving.  Data  logging  and  archiving  capabilities  will  support  the 
capture  and  storage  of  data  for  playback  and  analysis. 

4.4  Post  Test  Mission  /Training  Exercise  Analysis 

Post  Test  Mission  /Training  exercise  analysis  capabilities  will  include  Playback,  Data 
Extraction,  Visualization,  and  Data  Definition  capabilities: 

a.  Playback  Capability  to  reconstruct  exercise  or  test  events  from  messages  and  data  logged 
during  the  execution  of  the  logical  range. 

b.  Data  Extraction  Capability  to  extract  specific  data  elements  or  events  selected  from  the 
data  logged  during  the  execution  of  the  logical  range. 

c.  Visualization  Capabilities  to  support  data  analysis  uses  the  same  visualization 
capabilities  used  for  logical  range  execution  management. 

d.  Data  Definition  Capabilities  used  to  characterize  the  data  during  the  logical  range 
definition  phase  also  support  post  test/exercise  analysis. 


5.0  Summary  &  Conclusion 

Obviously,  the  task  of  reinventing  the  test  and  training  infrastructure  is  not  for  the  faint  of  heart. 
The  technical  issues  are  vast  and  complex,  but  they  are  meager  relative  to  the  cultural  and 
organizational  issues,  which  this  paper  does  not  begin  to  address.  There  indications,  however, 
that  the  time  may  be  right  to  begin  the  discussion.  The  Defense  Modeling  and  Simulation  Office 
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(DMSO)  High  Level  Architecture  (HLA)  and  other  DoD  M&S  initiatives,  such  as  the  Synthetic 
Environment  Data  Representation  &  Interchange  Specification  (SEDRIS),  the  Modeling  and 
Simulation  Resource  Repository  (MSRR),  and  the  Master  Environmental  Library  (MEL)  are 
positive  steps  toward  improved  interoperability.  In  addition,  DoD  Manual  8320.1-M-l,  Data 
Standardization  Procedures,  dated  November  1996  (Draft)  and  the  DoD  Range  Commander’s 
Council  (RCC)  Data  Interchange  Standard,  DR-19,  are  important  resources  for  achieving  this  end, 
as  the  Joint  Technical  Architecture  (JTA)  and  Defense  Information  Infrastructure  (DII)  Common 
Operating  Environment  (COE). 

Initial  Operating  Capability  (IOC)  for  FI  2010  is  defined  as  the  completion  of  a  Joint 
Test  Exercise  (JTE)  that  successfully  demonstrates  the  FI  2010  architecture  and  core  set  of 
products.  However,  during  the  execution  of  the  FI  2010,  products  supporting  the  functionality 
of  the  LR  will  be  developed  and  delivered  incrementally  to  the  ranges  and  facilities.  Full 
Operational  Capability  (FOC)  is  to  be  determined;  however,  it  is  anticipated  the  FI  2010 
architecture,  products  and  the  logical  range  concept  of  operations  will  continue  to  evolve 
indefinitely  after  IOC,  funded  by  non-CTEIP  mechanisms. 
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